REMARKS/ARGUMENTS 

The Office Action dated October 24, 2006 has been 
received and carefully studied. 

Claims 12-19 have been cancelled without prejudice. 

The Examiner rejects claim 2 under 35 U.S.C. §112, 
second paragraph as being indefinite for failing to 
particularly point out and distinctly claim the subject 
matter which applicant regards as his invention. 
Specifically, this Examiner states that the phrase ''the path 
between said server and said network'' lacks proper 
antecedent basis. By the accompanying amendment, claim 2 
has been modified to overcome this rejection. 

The Examiner rejects claims 1-8, and 20-25 under 35 
U.S.C. §102 (e) as being anticipated by Ikonen (U.S. Patent 
* No. 7,003,575). With respect to claims 1,3,24, and 25, the 
Examiner states that Ikonen teaches a method and a 
respective computer program for operating a computer 
network server in a computer network comprising maintaining 
a connection with a central node, receiving a command from 
said central node to open a listening port after central 
node receives a request from a client to access said 
server, opening a listening port, sending to the central 
node instructions for the client to connect to the server 
over the listening port and receiving communication from 
the client after the central node delivers a command to the 
client to connect to the server. 

This rejection is respectfully traversed. First, with 
respect to claims 1 and 24, those claims require that the 
server access the central node, obtain network addresses 
for the intended clients, and establish a connection to 
those clients. The Examiner does not recite these steps in 
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the Office Action, rather only the steps associated with 
claims 3 and 25 are discussed. Furthermore, this method of 
communication between the server and the client is not 
discussed in the Ikonen reference. Specifically, Ikonen 
does not disclose that the server establishes a connection 
to specific clients. Rather, Ikonen discloses that the 
client always initiates communication with the server. 
Thus, claims 1 and 24, and all claims dependent on those 
claims are believed to be in condition for allowance. 

With respect to claim 3, the Examiner states that 
Ikonen discusses all of the recited steps and cites 
specific passages in columns 8 and 9 for support. This 
rejection is respectfully traversed. Although not 
explicitly stated by the Examiner, it appears that the 
Examiner believes that the redirection database corresponds 
to the central node of the present claim. Assuming this 
configuration, Ikonen does not anticipate the present 
claim. The present claim 3 requires that the central node 
''receives a request from said at least one client to access 
said server". This communication is not disclosed by 
Ikonen. In fact, the client ALWAYS directly contacts a 
server, which then communicates to the redirection 
database. The client never communicates directly with the 
redirection database (i.e. central node) . Thus, the second 
step of the method recited in claim 3 is not anticipated. 

The present claim 3 also requires that the ''central 
node delivers a command to said at least one client". As 
stated above, the redirection database never communicates 
with the client in the Ikonen disclosure. Thus, the fifth 
step of the method recited in claim 3 is also not 
anticipated. 
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Furthermore, Ikonen discloses a method for solving a 
completely different problem than the present invention. 
Ikonen is concerned with sharing the load between a number 
of accessible servers. It accomplishes this by having a 
redirection database which determines whether a client, 
after making initial contact with a server, should be 
allowed to continue communicating with that server, or 
whether another server is a more appropriate target of the 
client's communications. In fact, claim 1 of Ikonen recites 
that method of communication begins with a packet sent from 
the client to a first server. In stark contrast, the 
present invention attempts to minimize access to the 
server, unless properly authorized by a central node. Thus, 
while the client initiates contact with the server in 
Ikonen as the first step of the process, such a client- 
server contact is the final step of the communication 
process in the present invention. All communications before 
that point are between the central node and the server or 
the central node and the client. Thus, claim 3 and all 
claims dependent on that claim are not anticipated by 
Ikonen and are believed to be in condition for allowance. 

The Examiner also rejects claim 25 for this same 
reasons listed above. Since claim 25 recites a computer 
program having the means to implement the steps recited in 
claim 3, it is not anticipated by Ikonen for the reasons 
stated above. 

The Examiner rejects claim 2, noting the Ikonen 
discloses a Network Translation device. Claim 2 is 
dependent on claim 1. As stated above, the Examiner never 
presented a prima facie case that claim 1 was anticipated. 
Thus, claim 2 by virtue of its dependence on claim 1 is 
believed to be allowable. 
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The Examiner rejects claim 4, stating that Ikonen 
discloses a predetermined listening time of less than one 
second. This rejection is respectfully traversed. Ikonen 
never discusses or discloses any information concerning the 
accessibility of the listening port, and clearly never 
discloses this time as being less than one second. 
Furthermore, this claim is allowable due to its dependence 
on claim 3, as described above. 

The Examiner rejects claim 5, stating that Ikonen 
discloses closing the listening port after receipt of a 
communication, noting that closing the port is inherent. 
This rejection is respectfully traversed. There is no 
disclosure that the server closes the listening port after 
receipt of the message. In fact, it is obvious that the 
listening port remains accessible since other clients can 
and are allowed to access the server. Furthermore, this 
claim is allowable due to its dependence on claim 3, as 
described above. 

The Examiner rejects claim 6, stating that Ikonen 
discloses establishing a network connection after receipt 
of a communication. This claim is allowable due to its 
dependence on claim 3, as described above. 

The Examiner rejects claim 7, stating that Ikonen 
discloses that the server closes its listening port if it 
receives communication from other than the authorized 
client, citing column 10, lines 1-30. Ikonen, neither in 
the cited passage nor anywhere in the specification, 
discloses that the server will close its listening port if 
accessed by an unauthorized client. In fact, as mentioned 
above, the server is generally available for communication 
from all clients, and thus such an action would not be 
beneficial for a load sharing application. Furthermore, 
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this claim is allowable due to its dependence on claim 3, 
as described above. 

The Examiner rejects claim 8, stating that Ikonen 
discloses a persistent connection with the central node. 
This claim is allowable due to its dependence on claim 3, 
as described above. 

The Examiner rejects claim 20, stating that Ikonen 
discloses a computer system, comprising a central node, a 
server and at least one authorized client, wherein said 
server is adapted to receive notification from said central 
node that said authorized client wishes to communicate with 
said server and in response to said notification, is 
adapted to open a listening port for said authorized client 
to connect to and sends instructions to said central node 
to notify said authorized client to communicate to said 
listening port. The Examiner cites the passages listed 
above for support. It is unclear from the Office Action how 
the Examiner interprets Ikonen to make this rejection. 
Ikonen describes two methods for load sharing, shown in 
Figures 7 and 8. If the Examiner is applying the method 
described in Figure 7, the rejection is improper. Claim 20 
requires that the server opens a listening port after being 
notified by the central node and then sends instructions to 
the central node to notify the client. In Figure 7, it is 
clear that the client communicates directly with the server 
before the central node ever notifies the server of the 
client's intention. Furthermore, the server never sends 
instructions to the central node to notify the client to 
communicate on the listening port (since communication is 
already occurring) . If the Examiner is applying the method 
shown in Figure 8, and treating server 1 as the "server" as 
recited in the present claim, the rejection is improper. 
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Server 1 conununicates with the client before any 
notification by the server. In fact, the notification that 
is received informs the server 1 to terminate, not 
initiate, communications with the client. Again, the server 
never sends instructions to the central node to notify the 
client to communicate on the listening port. Lastly, if the 
Examiner is applying the method shown in Figure 8, and 
treating server 2 as the "server" as recited in the present 
claim, the rejection is still improper. In figure 8, server 
2 is never notified by the central node of the client's 
desire to communicate. Rather, the only communication to 
which server 2 is a participant is between the client and 
server 2. Server 2 has no interaction at all with the 
central node. Thus, claim 20 and all claims dependent on 
claim 20 are believed to be in condition for allowance. 

The Examiner rejects claim 21, stating that the server 
is adapted to close the listening port if an unauthorized 
client attempts to communicate. As explained above, this is 
not disclosed in Ikonen, and would not be beneficial to a 
load sharing application where multiple clients are in 
communication with multiple servers. Furthermore, this 
claim is allowable due to its dependence on claim 20, as 
described above. 

The Examiner rejects claim 22, stating that Ikonen 
discloses establishing a network connection after receipt 
of a communication. This claim is allowable due to its 
dependence on claim 20, as described above. 

The Examiner rejects claim 23, stating that Ikonen 
discloses closing the listening port after receipt of a 
communication, noting that closing the port is inherent. 
This rejection is respectfully traversed. There is no 
disclosure that the server closes the listening port after 
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receipt of the message. In fact^ it is obvious that the 
listening port remains accessible since other clients can 
and are allowed to access the server. Furthermore, this 
claim is allowable due to its dependence on claim 20, as 
described above. 

The Examiner rejects claims 9-11 as being unpatentable 
under 35 U.S.C. §113 (a) over Ikonen. The Examiner takes 
official notice that encrypting communication packets is 
old and well known in the art for establishing secure 
communications. However, these claims are allowable due to 
their dependence on claim 3, which is believed to be in 
condition for allowance, based on the earlier arguments. 

Reconsideration and allowance are requested in view of 
the foregoing arguments. 
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